1. Field of the Invention
This invention generally relates to automated testing processes and, more particularly, to a system and method for automatically generating a plan for the testing of a microprocessor-driven software application.
2. Description of the Related Art
Computer software applications, such as Microsoft Windows-based applications, applications that appear like Windows applications, or other graphical user interface (GUI) applications are typically tested by quality assurance (QA) before distribution to the public, using test programs. The QA team usually installs the application and attempts to interact with the application using the interface provided by the application. This interface typically involves the selection of menu options and opening any dialog boxes provided by the application. QA will often attempt things unexpected by the program designers, such as the entry of invalid data. The test program can be automated to capture the user's interactions with the application and convert them into scripts. These scripts can be run and compared with subsequently tested versions of the application, to verify that the application is reacting as expected.
FIG. 5 is a flowchart illustrating a manual, human operator, process of generating a test plan (prior art). The problem with this approach is it relies on the expertise of the QA operator to identify all possible alternative routs in the exercise of a given feature or menu option. Often, a number of bugs are reported by the users of the application in the field, relating to features or options that QA did not identify or test using the test plan. Thus, the quality of the test plan is dependent upon the expertise of QA operator and/or their knowledge of the product and product field.
Another problem in the development of a high quality test plan results from the fact that QA typically only gets involved with the application during the final phases of the product development. In fact, QA often gets involved only during the release phase of the product. In an overwhelming majority of cases, a QA operator receives an application and is asked to test the application with out any documentation describing what, or how the testing should proceed.
The above-mentioned testing problems are compounded by the fact that the same application is expected to operate identically on a number of different computer operating systems. For example, a Windows application is typically expected to work with all, or most of the Microsoft operating systems currently in use by the public. Further, the application is expected to operate the same, regardless of the human language (i.e., English) used.
It would be advantageous if a software application test plan could be developed that fully exercised every menu and option presented by the application user interface (UI).
It would be advantageous if the above-mentioned test plan could be developed in response an automatic testing program that fully exercised all the possible options presented by an application UI.